Experimental BBS Explossion 3/Experimental BBS Explossion III.iso/gus/sdkdigv2.zip/SDKV2N31.TXT

Text File | 1993-07-30 | 10KB | 233 lines

GUS Programmer's Digest     Fri Jul 30 00:07     Volume 2: Issue  31

Today's Topics:
                    GUS Programmer's Digest V2 #30
                            SDK questions
              WARNING: Lists running blind for a week...

Standard Info:
    - Meta-info about the GUS can be found at the end of the Digest.
    - Before you ask a question, please READ THE FAQ.

----------------------------------------------------------------------

Date: Thu, 29 Jul 1993 12:51:56 -0400
From: jericho!gord (Gord Wait S-MOS Systems Vancouver Design Center)
Subject: Re: GUS Programmer's Digest V2 #30
Message-ID: <[e-mail]>

RE: SDK questions:

The only question I can help you on is the centerpoint. I beleive
the centerpoint to be 80 hex. I don't know if there is an "official"
spec on this. Note that if you use USS8 and fade a section of audio
to completely 0, that it ends up at 80 hex. Note also that the GUS's 8 bit
in ports are not well zero'ed. My card zero's out at 7e (left channel)
and 81 (right channel). Other peoples cards are different. I wrote
a little test and fix program (sndfix.zip in the archives) to find out
what your card is set to, and then use the program as a filter to
correct samples after they are recorded. (IE add or subtract to set
the sample back to 80 hex as a center point).

I wrote this after I found pops and clicks while pasting audio samples
into sections of silence in USS8.

------------------------------

Date: Thu, 29 Jul 93 4:58:16 EDT
From: Phat H Tran <[e-mail]>
Subject: SDK questions
Message-ID: <[e-mail]>

> Date: Wed, 28 Jul 1993 12:11:07 -0700 (PDT)
> From: [e-mail] (Dave Roberts)
> Subject: SDK Doc Questions still
> Message-ID: <[e-mail]>
>
[...]

I was also waiting for a reply to your message as well to see if what
I've internalized about the GUS after reading the SDK doc is close to
reality.  But since no one has replied, I'll give you my version of
the answers to your questions and hope people will correct me where
I'm wrong. :)

> Question #1:
>
> How does looping work?  Specifically, how does reverse looping
> operate?  What are the end points?  What are all the various looping
> options?  The docs mention resetting end points to deal with sampled
> decays.  What are the exact steps involved with this?  How do you
> handle decay without using a sampled decay?  Just a volume ramp down
> until you get to zero and then shut off the voice?
>

On the most basic of levels, a voice can play a sample with three points:
the sample begin point, the loop start point, and the loop end point.

            |-----------------|--------------|
          Begin             Start           End
               --> direction of voice travel

These points are all absolute addresses in the GUS' DRAM, not table
offsets.  You would store the Begin address in registers 0Ah & 0Bh
(these hold the current address of the voice), the loop Start address
in registers 02h & 03h, and the loop End address in registers 04h & 05h.
Once the appropriate bits are set and cleared in the control register,
the voice will start advancing in the direction shown.  Note that the
registers used to hold the Begin address (0Ah & 0Bh) will get updated
as the voice moves, so they must be restored if you want to restart
the voice.  Once the voice hits the End address, the address in
registers 02h & 03h will be loaded into registers (0Ah & 0Bh), thereby
repositioning the voice at the Start address, and the voice will
continue advancing from that point.  This repeats for as long as looping
is enabled.  For note-off, a volume ramp to zero can be used to synthesize
a decay.

You can also implement a sampled decay.  Consider the following sample
uploaded to the GUS:

            |-----------------|-------------|----------------|
          Begin             Start          End           Decay End
               --> direction of voice travel

The Begin, Start, and End address are all stored in the same registers
as in the previous case.  Starting the voice (with looping enabled)
through the control register is also done in the same manner as before.
The difference is that for note-off, instead of implementing a volume
ramp, looping is first disabled, and then the Decay End address is
stored in registers 04h & 05h (which used to hold the loop End address).
That way, instead of looping the segment between Start and End, the voice
wanders off into the sampled decay, and stops once it hits the end.

Reverse looping is identical except that the sample points are flipped
around and the Starting Address and Ending Address registers swap
roles (I think).  Anyway, there's not much use that I can see in
reverse looping.  Bidirectional looping, OTOH, can be useful.  Same
concepts as above, but instead of snapping back to Start once it
hits End, the voice just reverses direction.  It reverses direction
again once it hits Start, and so on.

>
> Question #2:
>
> The voice control registers have bits that can be modified at any time
> by the GF1.  The GF1 does a read-modify-write cycle to update these
> bits.  The SDK docs say that when writing to a register containing one
> of these bits that the software should write the value twice,
> separated by a delay (which is specified by I don't remember).  Anyway,
> this is all fine and dandy, but imagine this situation.
>
> Voice control reigster, bit 6, controls the direction of movement
> through the wave.  What if I (the program) want to update a bit in the
> register.  I read the register value, modify the bit I want, and write
> it back twice.  What if the GF1, between the program's writes changes
> the direction of movement bit (because it was set to a loop mode and
> hit the end of the loop points and is now bouncing back the other
> way)?  The problem that I see is that I (the program) will end up
> setting the direction of movement bit back to the old value, which
> will start the wave back bouncing the other way before it reaches the
> other loop point.  Am I right with this, or do I not understand
> looping?  Is this a problem?  Is there a workaround other than, "don't
> do that"?
>

Good question!  Here's a possible solution:  Before the second write,
read the register again and note what state bit 6 is in and set bit 6
of the byte that you're re-writing to the control register to the same
state.  The reread must take place after the delay.  That way, if bit 6
changes during the access period, its new state will be reflected in
the second write to the register.

The GUS occasionally squawks, so I think that its current drivers
are corrupting some of its self-modifying bits.  Perhaps a read
before the second write to protect sensitive bits will get rid of
these squawks?

> Question #3:
>
> One page 4 of the SDK docs they are describing volume ramping.  There
> is a table that describes the rate bits.  The table mentions something
> called a "FUR".  What's a FUR?
>

Just an adhoc term defined for the formulae on that page, I presume.

> Question #4:
>
> What is the centerpoint for unsigned waveforms, 7F or 80 (hex)?
>

I think it could be either.  But the GUS uses signed data internally,
and when it converts 7Fh to signed form (by inverting bit 7 during the
DMA transfer), it comes up with -1.  OTOH, converting 80h to its signed
form by the GUS' method yields 0.  Therefore, use 80h as the centrepoint
for your unsigned data.

> Thanks for any help you gurus might be able to give.
>

You're welcome.  I hope I haven't made any serious mistakes.  I'm not
really a programmer, nor an engineer, but a biochem student, so you're
taking your chances with my "help". :)

Phat.

------------------------------

Date: Thu, 29 Jul 1993 15:11:01 -0600 (CDT)
From: [e-mail] (Dave DeBry)
Subject: WARNING: Lists running blind for a week...
Message-ID: <9307292111.AA06617@grue>

    [This message is being sent to all the lists I maintain.  If
you are multiple lists, you're going to get multiple copies.  Live
with it.]

    I'm going to be out of town (at SIGGRAPH, actually... if you
are going, let me know... it would be nice to meet some of you) and
away from the mailing lists until August 9th.  You folks are all big
grown-up list users now, so Mom and I decided it's okay to leave you
alone for the week.  (Now watch us get hauled off to jail like that
couple from Chicago. :) The emergency numbers are by the phone,
there's a lot of food in the pantry...

    If any trouble comes up, deal with it.  If anything REAL bad
comes up, mail to [e-mail].  This is only in the worst
case scenario though; their solution will be to just shut all the
lists down until I get back (and then I might not be allowed to turn
them back on).

    Have fun while I'm gone.  You can have friends over, but no
big parties.  Ahem... Mike?  Yes, you.  Mr. Biesele.  Pay attention.
(Inside joke.  Most of you can just ignore it.)

--
Dave  ddebry@ debry@   \
DeBry dsd.    peruvian. | "All right!  I admit it!  I wash my socks in
      es.     cs.utah.  |  club soda so my feet will fizz!"
      com     edu      /

------------------------------

End of GUS Programmer's Digest V2 #31
*************************************

To post to tomorrow's digest:               <[e-mail]>
To (un)subscribe or get help:       <[e-mail]>
To contact a human (last resort):     <[e-mail]>

FTP sites:         archive.epas.utoronto.ca         pub/pc/ultrasound
                   wuarchive.wustl.edu       systems/msdos/ultrasound
Hints:
      - Get the FAQ from the FTP sites or the request server.
      - Mail to <[e-mail]> for info about
    other GUS related mailing lists (UNIX, OS/2, GUS-MIDI, etc.)